1. Field of the Invention
The present invention relates to a method for enhancing a Principal Referencing scheme by enabling an inviting principal to control the access an invited principal has to their resources/resource offerings.
2. Description of Related Art
The following abbreviations/definitions are provided to help describe both the prior art and the present invention.
APAttribute Provider. For the purpose of thepresent discussion, this term is equivalentto that of Web Service Provider.ARAttribute Requestor. For the purpose of thepresent discussion, this term is equivalentto that of Web Service Consumer.AttributeFor the purpose of the present discussion,this term is equivalent to resource.Circle of TrustA federation of service providers andidentity providers that have businessrelationships based on LAP specificationsand operational agreements and with whomusers can transact business in a secure andapparently seamless environment.CoTCircle of Trust.DSDiscovery Service. An identity servicethat allows requesters to discoverthe resource offerings for a specificPrincipal.DSRODS Resource Offering. The DS ResourceOffering is the set of data that enables aservice provider (attribute requestor) toobtain from a DS the resource offerings ofa given principal.DSTData Services Templates. An XML-basedprotocol defined by LAP to define the waythe parties (WSPs, WSCs and DS) interactwhen locating and accessing resources.FederationThe act of establishing a relationshipbetween two entities. In this context,federation is the act of establishing arelationship between a service providerand an identity provider with regard to agiven principal.HTTPHyper Text Transfer Protocol.ID-FFIdentity Federation Framework.ID-SISIdentity Services InterfacesSpecifications.ID-WSFIdentity Web Services Framework.Identity ProviderAn identity service that providesprincipal authentication to other serviceproviders within a circle of trust.Identity-Based An abstract notion of a WebWeb ServiceService that acts upon someresource to either retrieveinformation about a principal,to update information about aprincipal, or to perform someaction for the benefit of aprincipal. For simplicity, thisterm is sometimes abbreviated asIdentity Service.IdPIdentity Provider.Inviting PrincipalThe principal who initiates the invitationmechanism in order to enable some onlineinteraction between themselves and someother principal or group.Invited PrincipalA principal who is invited by another toparticipate in some online interaction.InvitationAn electronic mechanism by which thenecessary consent can be obtained and therequired federations established in orderto enable cross-principal onlineinteractions. To summarize, it isthe process that enables subsequent accessto resources of a given principal by WSCsacting on behalf of principals that havebeen invited by the inviting principal.LAPLiberty Alliance Project.Name IdentifierThe principal's identifier shared betweena service provider and the principal'sIdentity Provider. Both parties share suchan identifier once the federation processhas taken place.PIKSPeople I Know ServicePIKSPPeople I Know Service Provider. A LibertyID-WSF Identity Service that maintains, forprincipals, a list of the other principalsthat have been previously invited toparticipate in online interactions andmakes this information available toauthorized requestors.PrincipalAn entity whose identity can beauthenticated (in broader terms, a user).Principal ReferencingIs a mechanism by which differentapplications can share information (onlineresources) with invited users within aninviting user's social network, while suchinformation and the conditions under whichthe information is released are under thecontrol of the inviting user (via the useof Liberty ID-WSF).ResOffResource OfferingResourceEither data related to some principal orgroup of principals or a service acting onbehalf of some principal or group ofprincipals. Examples of differentresources are Alice's location, theYahoo instant messaging service for Aliceor the Yahoo instant messaging service forBob.Resource OfferingSet of data that enables a service provider(attribute requestor) to locate andinteract with an AP. It represents theassociation of a resource and a serviceand contains the resource ID, theservice type, the provider ID, the protocolendpoint and the description of theservice.SAMLSecurity Assertion Markup Language.Security TokenA security token represents a collection ofstatements regarding qualitiescorresponding to a user/entity, which canbe used for security purposes.Service ProviderA role donned by system entities. From aprincipal's perspective, a ServiceProvider is typically a website providingservices and/or goods.SharedIdA principal's identifier shared betweentwo parties.SharedId(B) Principal B's identifier shared(DS-A - DS-B)between their own DiscoveryService and another principal's(typically a principal that hasinvited him or her) DiscoveryService.SharedId(B) Principal B's identifier shared(DS-A - WSP-A)between their own DiscoveryService and a WSP where s/he has beeninvited by another principal. Thisidentifier is normally identical tothe name identifier shared betweenthe WSP-A and principal B's IdentityProvider so that it can be reusedinstead of creating a new identifier.Single Sign-OnAbility for end-users to perform oneauthentication and, as a result, beallowed to access different resourcesand services.SOAPSimple Object Access Protocol.SSOSingle Sign-On.URLUniform Resource Locator.WSCWeb Services Consumer. A role donned by asystem entity when it makes a request to aweb service. For the purpose of the presentdiscussion, this term is equivalent to thatof Attribute Requestor.WSPWeb Services Provider. A role donned by asystem entity when it provides a webservice. For the purpose of the presentdiscussion, this term is equivalent to thatof Attribute Provider.
The Liberty Alliance Project (LAP) is a consortium representing organizations from around the world which has been created to address various technical, business and policy challenges associated with identity and identity-based web services. To this end, the LAP has developed a set of open technical specifications related to identity and identity-based web services. The particular specification which is relevant to the present discussion is informally known as the Principal Referencing specification (and formally known as the People I Know Service (PIKS) specification).
The Principal Referencing specification enables a first user (inviting principal) to specify a group of friends (invited principals) and then invite and let those friends access one or more of their resources/attributes. For instance, the Principal Referencing specification could enable the following scenario: a friend (invited principal) is willing to have lunch with you (inviting principal) if you happen to be located nearby. To find out, the friend needs to access your location information provided by your mobile operator. Apart from that, the friend might also be interested in finding out your preferences regarding your favorite restaurants (accessing your lunch/dinner profile). And, maybe the friend before trying to contact you would like to see if you are even available for lunch (accessing your online calendar). In this case, the shared resources to which your friend would like to access include your location information, your lunch/dinner profile information and your calendar information. The type of device used by the friend could be a mobile phone, personal computer or any other type of device so long that it is a web services-enabled device which is able to work as Web Service Consumer (WSC) or a HTTP-enabled device which contains a browser.
Principal Referencing was first discussed by LAP in a document which is entitled “Principal Referencing”, Version 1.6 2004-09-17. The contents of this document are incorporated by reference herein. This document considers two different cases of attribute sharing:
1. The shared resource is accessible via a web browser (attributes hosted by a service provider).
2. The shared resource is accessible via a Web Services-based interface (attributes hosted by a Web Service Provider—WSP). The examples reflected in this discussion focus mainly on this use case, but this does not imply that the applicability of the present invention is restricted to this scenario. On the contrary, the present invention could be applied to the former use in which the shared resource is accessible via a browser.
According to this Principal Referencing specification, the principal wishing to access resources belonging to another principal is named invited principal (the term “invited” is used here because s/he has to be invited by another principal before being allowed to access the resources of that principal). And, the principal whose resources are accessed, by a WSC on behalf of the invited principal is named inviting principal (this user has invited the principal on behalf of which the access to resources is performed; that is, the invited, principal). The invited principal is frequently referred to herein as principal-B (plus the terms DS-B and the WSC-B and the like are used herein as well). And, the inviting principal is frequently referred to herein as principal-A (plus the terms DS-A and the WSP-A and the like are used herein as well). FIG. 1 (PRIOR ART) is a diagram, which illustrates a WSC-B accessing the inviting principal-A's resources from the WSP-A (which has no access control) on behalf of the invited principal-B.
Unfortunately, this Principal Referencing specification has several problems all of which are described in detail below with respect to the signal sequence chart shown in FIGS. 2A-2C (PRIOR ART). This signal sequence chart illustrates how a principal is invited and then how that invited principal accesses the attributes/resources of an inviting principal. The steps are as follows:
1. Inviting Principal-A attempts to access WSP-A.
2. WSP-A sends an authentication request regarding the inviting principal-A via the inviting principal-A to IDP-A.
3. IDP-A sends an authentication response (with nameID and DSRO-A) for the inviting principal-A via the inviting principal-A to WSP-A.
4. WSP-A sends a GET PIKSP-A Res Off (including DSRO-A) message to DS-A to get the resource offering of PIKSP for inviting principal-A.
5. DS-A sends a PIKSP-A Res Off message to WSP-A, including the resource offering of PIKSP for inviting principal-A. Note: steps 4 and 5 are associated with the discovery of PIKSP-A.
6. WSP-A sends a query message to PIKSP-A to obtain the list of inviting principal-A's friends (principals previously invited by inviting principal-A).
7. PIKSP-A sends a query response message to WSP-A containing such a list.
8. WSP-A displays the current members of the inviting principal's friends group. Note: the invited principal-B is not a current member of the friends group (see box 1.0).
9. Inviting principal-A tells WSP-A to assign permissions to new invited principal-B.
10. WSP-A sends a modify message (associated with, inviting the invited principal-B, identified by a user friendly text string) to PIKSP-A.
11. PIKSP-A sends a modification response message (associated with inviting the invited principal-B) which contains an invitation URL InvURL1 and a temporal user identifier tempID-B to WSP-A. Note: (1) the InvURL1 contains the means for the PIKSP-A to correlate further requests related to invited principal-B; (2) the InvURL1 belongs to the PIKSP-A web domain; and (3) the WSP-A uses tempID-B to assign privileges to invited principle-B and stores InvURL1 (see box 1.1).12. WSP-A delivers an invitation message (including an invitation. URL InvURL2) to invited principal-B. Time passes (see box 1.2). Note: (1) the InvURL2 belongs to the WSP-A web domain.13. Invited principal-B sends InvURL2 to WSP-A.14. WSP-A sends a REDIRECT InvURL1 message (including return URL backURL) via invited principal-B to PIKSP-A, Note: (1) the backURL belongs to the WSP-A web domain and allows the PIKSP-A to send back the invited principal-B to the WSP-A.15. PIKSP-A sends an authentication request regarding the invited principal-B (including temporal user identifier tempID-B) via invited principal-B to IDP-B. Note (1): the tempID-B is the temporal user identifier quoted in step 11 and associated to InvURL2 so that the PIKSP-A is able to correlate the invited principal-B with the right invitation process.16. IDP-B sends an authentication response (including tempID-B, nameID and DSRO-B) for the invited principal-B via invited principal-B to PIKSP-A. Note: steps 15 and 16 relate to the federation of the identity of invited principal-B at PIKSP-A (see box 1.3).17. PIKSP-A sends a discovery update message (including DSRO-A) to DS-B. Note: PIKSP-A registers DSRO-A at DS-B (thus DS-B knows which users have invited DS-B's users) (see box. 1.4).18. DS-B sends an OK message to PIKSP-A.19. PIKSP-A sends a REDIRECT backURL message via invited principal-B to WSP-A. Note: this begins the federation of B's identity in WSP-A.20. WSP-A sends an authentication request regarding the invited principal-B via invited principal-B to IDP-B. Note: IDP-B knows that tempID-B is the temporal user identifier quoted in step 11 and is associated with WSP-A (see box 1.5).21. IDP-B sends an authentication response (including nameID, tempID-B and DSRO-B) for the invited principal-B via invited principal-B to WSP-A. Note: (1) steps 20 and 21 relate to the federation of the identity of invited principal-B at WSP-A (see box 1.6); and (2) WSP-A transfers privileges to the user with nameID and removes tempID-B (see box 1.7).22. Invited principal-B attempts to access WSC-B. Note: this step begins the process of discovering and sharing the attributes of the inviting principal-A.23. WSC-B sends an authentication request regarding invited, principal-B via invited principal-B to IDP-B.24. IDP-B sends an authentication response (including nameID and DSRO-B) for the invited principal-B via invited principal-B to WSC-B. Note: this completes the SSO to WSC-B (see box 1.8).25. WSC-B welcomes inviting principal-B to WSC-B.26. Invited principal-B sends a request to WSC-B to get a list of people (including the inviting principal-A) that have invited them to access their resources/attributes.27. WSC-B sends a GET message (requesting both a list of people that have invited principal-B and the DSRO for each of the people on that list) to DS-B.28. DS-B sends list of friendly names and DSROs of the inviting principals (including the inviting principal-A) to WSC-B.29. WSC-B sends a message asking the invited principal-B which friend (the inviting principal-A) from this list of inviting principals (including the inviting principal-A) has to be chosen.30. Invited principal-B indicates to WSC-B that the friend is inviting principal-A. Note: WSC-B has the DSRO-A (see box 1.9).31. WSC-B sends a message asking the invited principal-B which attribute of inviting principal-A that they would like to obtain/access.32. Invited principal-B sends a message to WSC-B indicating that they want to get attribute of type “X”.33. WSC-B sends a message <disco> requesting inviting principal-A's attribute of type “X” to DS-A. Note: DS-A just knows the users (including invited principal-B) that have been invited by inviting principal-A. As such, DS-A does not know which particular attribute(s) that the inviting principal-A wants to share with this particular invited principal-B (see problem 1 in box 1.10).34. DS-A sends a message (including the resource offering of the inviting principal-A's attribute of type “X” (which is shared by the WSP-A)) to WSC-B. Note: DS-A did not receive any reference to invited principal-B. As such, DS-A can not apply any type of access control to the resource offering of the attribute (s) with respect, to invited principal-B (see problem 2 in box 1.11).35. WSC-B sends a get attribute of type “X” message to WSP-A using the attribute's resource offering received in step 34.36. WSP-A sends the attribute of type “X” to WSC-B. Note: WSP-A does not receive any reference to invited principal-B. As such, WSP-A can not apply any type of access control to the attribute (s) with respect to invited principal-B (see problem 3 in box 1.12).37. WSC-B makes attribute of type “X” available to invited principal-B.
The cornerstone of the Principal Referencing specification is the identity service named PIKSP (People I Know Service Provider). As indicated, the PIKSP has the responsibility of keeping the lists of friends of each inviting principal-A and managing the invitation process on behalf of the inviting principal-A. In particular, the PIKSP's main functionalities are as follows:                The PIKSP functions to guarantee that the invited principal-B federates his/her identity with WSP-A (where the WSP-A is the WSP from which the inviting principal-A is triggering the invitation process). The PIKSP requires that the invited principal-B have an identifier (possibly a secured identifier) so it can perform an authentication and make an authorization decision.        The PIKSP functions to maintain a list of the principals who are invited by each inviting principal-A as well as the service providers where each inviting principal-A has invited each of the invited principals-B. The service providers (either with a Web Service interface, i.e. a WSP, or by means of a web browser, i.e. a SP, or with both) are identified by means of a unique provider identifier ProviderID. It is assumed that, by being an identity service, the PIKSP keeps lists of invited, principals for each of its own users; that is, physically speaking there can be several PIKSPs in the same CoT, each of which handles a group of inviting principals. The PIKSP can also keep the federated, identifiers of each invited principal-B and the service providers (SPs or WSPs) where they have been invited. However, if before the invitation process, the invited principal-B has not federated an identifier at the WSP-A, then the specification provides the means for the invited principal-B to federate his/her identity with the WSP-A (see steps 20-21 in the invitation process Shown in FIG. 2B). Below, there is a rough description of the data that can be stored, within the PIKSP.        
Principal Al   Friendly name of invited principal B1 assigned by Al     Name Identifier of B1 at Service Provider 1 (SP1)     Name Identifier of B1 at Service Provider 2 (SP2)     Name Identifier of B1 at Service Provider n (SPn)   Friendly name of invited principal B2 assigned by Al     Name Identifier of B2 at Service Provider n (SPn)   Friendly name of invited principal Bm assigned by Al     Name Identifier of Bm at Service Provider 2 (SP2)     Name Identifier of Bm at Service Provider n (SPn)Principal An   Friendly name of invited principal B1 assigned by An     Name Identifier of B1 at Service Provider 1 (SP1)   Friendly name of invited principal B3 assigned by An     Name Identifier of B3 at Service Provider n (SPn)                The PIKSP functions to register in the DS of each principal invited by any of its users the DS Resource Offerings of all the principals that have invited him/her (that is, the DS of a given invited principal has a reference of all the principals that have invited him/her, by means of their DSROs). Thus, with regard to Discovery Services, the result of an invitation process is to update the invited principal's DS (DS-B) with references to all the principals that have invited them. No action is taken regarding the inviting principals' DS (DS-A).        The PIKSP does not play a role in the discovery and sharing of inviting principal's attributes.        
To summarize, this Principal Referencing scheme comprises two main procedures: (1) the invitation process (here, the inviting principal-A invites another principal-B at a given WSP-A with the support of the PIKSP-A); and (2) the discovery and access to resources process. The result of the invitation process is as follows:                The identity of the invited principal-B is federated with PIKSP-A (if it was not yet).        The identity of the invited principal-B is federated, with WSP-A (if it was not yet).        The PIKSP also keeps, for each user, the list of his/her friends, identified by a friendly name and, as long as their identity has been also federated, a pointer to the identity management infrastructure of the invited principal-B. This pointer can be in the form of the ProviderId of IDP-B, which uniquely identifies it, but it could also include any other type of pointer such as DS-B RO.        
With regard to the discovery and access to shared resources process, the basic steps include the WSC-B accessing the DS-B of the invited principal-B and getting the list of principals that have invited him/her (including their DSROs). The WSC-B with this data is then able to query the Discovery Service-A of the inviting principal-A and, discover/obtain his/her resources/attributes (see FIG. 2C).
Unfortunately, the traditional Principal Referencing scheme lacks a number of different features to work properly. The main problem is that inviting principals who expose resources are not able to properly control the access to such resources or to their resource offerings. This problem is caused because the DS-A and the WSP-A do not know the user (invited principal-B) on behalf of which the WSC-B is accessing them so these entities cannot enforce any access control policy. Another problem is the lack of granularity with regard to shared resources. In particular, when a WSC-B on behalf of an invited principal-B wishes to access resources, it may access DS-B to get the list of inviting principals (and their DSROs) that have invited principal-B. Next, the WSG-B may access the appropriate DS-A to get relevant resource offerings of the inviting principal-A. However, the DS-A has not been involved in the invitation process which means it is not able to determine which attributes, from all the types of attributes the WSP-A hosts, the inviting principal-A wishes to share with the particular invited principal-B. In fact, the DS-A does not even know that WSC-B is accessing it on behalf of a principal other than inviting principal-A. It should, be noted that the LAP has since updated this Principal Referencing specification to address some of these problems but the new specification is very complex and has a heavy signaling load. Thus, there is still a need for a principal referencing scheme which can effectively address these shortcomings and other shortcomings. This need and other needs are addressed by the present invention.